Some systems have an object model (also referred to in the art as an “object-oriented model”) that maps to a relational database, and this may be referred to as an “object-relational database”. The object model is mapped to the relational database.
The object model describes the properties of objects and is defined using, for example, class (which defines a particular type), inheritance (which defines a relationship between objects), polymorphism (which is the ability to create a variable, a function, or an object that has more than one form), and enumeration (which is an ordered list of a set of objects).
The ability to generate reports from the relational database content using existing reporting tools allows data to be published at a lower cost and in a way that can be customized to different groups of people. These reports are typically designed using a reporting model that is created from the relational database.
A relational schema describes a structure of a relational database. A relational schema may be generated to store object models (such as those designed using Uniform Modeling Language (UML) or JAVA®). (JAVA is a trademark or registered trademark of Oracle Corporation in the United States, other countries, or both.) However, such a relational schema may not be suitable for access from outside an Object-Relational Mapping (ORM) system. Therefore, reports may not be generated accurately from such a relational schema.
Some systems use Structured Query Language (SQL) views. A SQL view may be described as resulting from execution of a stored query on data in the relational database, and this SQL view may be queried just as the data in the relational database may be queried.
SQL views, while allowing names and types to be reconciled between the relational database and object model, do not inherit some of the semantics defined in the relational schema on which they are defined. For instance, primary and foreign keys defined on a given table are not “inherited” by SQL views defined from that table. That is, the SQL views do not include relationship information. In other words, the primary and foreign keys are not part of a view definition in the database catalog, and are therefore not available to the reporting tools to infer relationships. A primary key may be described as one or more keys in a table that uniquely defines the characteristics of each row in that table. A foreign key may be described as one or more fields in a first table that uniquely identifies a row of a second table.
For example, most commercial database systems do not propagate the referential constraints of the underlying tables on which a SQL view is defined to the SQL view in the database catalog. Therefore, a reporting tool relying on the database catalog to generate a reporting model is not able to infer the original model relationships. In particular, the reporting tools use a reverse engineering process that involves inference of relationships among model entities based on relational constraints (e.g., foreign keys) and/or name matches. The reporting model designer usually has to review the inferred relationships to perform any necessary adjustments (e.g., missing relationship, wrong cardinality, etc.). That is, the report designer has to reconcile the semantics of the original object model and the persistent relational schema.